Hi there!

So, first thing that comes to mind.

We ended up running into some issues when wrapping zsh that might be relevant here as well.

Basically, nixpkgs has an /etc/set-environment script

And home manager likely has things in its profile paths as well to source.

Both of those have the ability to overwrite things we provide via the wrapper.

#295 (reply in thread)

^ context for the issues we ended up running into.

Basically, we ended up generating the entire wrapper into the config file, so that we run after that gets sourced

https://github.com/BirdeeHub/nix-wrapper-modules/blob/708dd619b5096f93c55ccef25af9cae5e57d4190/wrapperModules/z/zsh/zshenv.nix

I am not sure if any of that is relevant for fish, but that would be the first things to test.

Depending on when this gets ran, we may or may not run into the same issues.

These links may or may not be useful as well, they are the relevant PRs for when the zsh wrapper was added and also for a fix that was needed for it.

There may be some useful information in there, if you do end up finding that there are similar issues here as well

#347

#355

#356

After some testing, it seems a change to an environment variable in the wrapper is kept even if it has an override in /etc/set-environment.

As for #295 (reply in thread), config.extraPackages works completly fine.

And for that, the fish arg --no-config is set, so only the wrapper's configration is used (I think the same applies to the home-manager stuff).

Ok I will check it out sometime this week on my system to make sure everything is good :)

Somewhat hesitant about --no-config, worried that will make it so that some things are not provided by nixos or home manager

After reading #326 I have harnessed the understanding of spec and dag/dal. And will implement it in the soon to come commits. You should add the example you gave in #326 (comment) to the docs.

I had a hard time understanding the spec type before I read that discussion.

I still have a few days until I can try this out, Im glad you were able to figure out how the spec type works!

One thing to keep in mind with them is that they are slightly harder to override than a normal submodule option when it comes to overriding fields that are not the main one, (although you still can, hence wlib.ignoreSpecField), so use the DAG type specifically when the value definitely has a single defined main field where the normalization is useful enough, or needs to match another option which is a DAL.

The DAL type, however, can generally be freely used instead of a list, because you already couldn't override a list like that.

I agree documentation on them could be improved. But also docgen could be improved too, and there are still several core pieces of the project to write, (which I now have added to the readme actually).

I have trouble picking which thing to work on, and unfortunately, improving written documentation is often not the one I pick.

The reason it is taking me a while to get around to trying this one out, is because the specific thing I want to try out is using it as the default system shell, and that is somewhat of a bigger ordeal than just building and running a program is, so I need some time I can set aside for that rather than just poking at it while I am doing other things, so, thank you for being patient.

Good thing you mentioned default system shell, I tried that myself, but I didn't add the attribute "shellPath" to the derivation